Computer graphics applications, in particular computer games, can be very expensive to develop. Unfortunately, they are also a popular target for software pirates, possibly because of the number of potential users. In the past, piracy was usually partially limited by supplying the application on a physical medium, e.g., either a ROM cartridge or a ‘difficult to copy’ disc, or by shipping a physical key, e.g. dongle. It is envisaged, however, that software will increasingly be sold electronically, e.g. downloaded from the Internet or from a ‘point of sale’, POS, terminal in a shop. This lack of a physical medium would thus potentially make illegal copying a far simpler task unless other measures are taken.
The protection of software against piracy has relied on several techniques in the past. One such technique is the use of a difficult to replicate physical medium for storage of the software application. For instance, some computer games console manufactures have used “Read Only Memory” (ROM) cartridges, or proprietary variants of common media such as higher density CD ROMs for which no off-the-shelf duplication tools exist.
An alternative technique often used for personal computers is to use standard media, such as floppy disks or CDs, but deliberately ‘damage’ them in small areas during manufacture using, say, a laser. The application software then contains instructions to check that the supplied storage medium contains these errors. An off-the-shelf floppy drive or CD-Rom ‘burner’ would not be able to reproduce the error on the medium. Although the checks for the errors can be hidden within the software to a certain extent, given sufficient time a determined cracker can locate them and produce a modified version of the application with the checks removed. This ‘cracked’ software could then be stored and run using off-the-shelf media.
Another method of protecting the contents of the software from being modified would be to use a ‘secure’ CPU which could encrypt all transfers to and from external memory. Such processors, however, are not common and this may not be a viable option for the manufacturer of a computer graphics device. Furthermore, on its own this does not prevent copying of the application, only its modification.
Some devices, such as ethernet adapters and some computers, are constructed with an in-built unique identifier. We have appreciated that this identifier could be used to customise software so that it runs on only one machine. Again, unless other steps are taken, this would be open to abuse by modification of the software that removes the checks.
The present invention in particular deals with systems and applications doing 3D computer graphics rendering. A typical known environment is illustrated in FIG. 1a. Here a CPU 1 is connected to memory 2 that would contain the application code and data structures. The application would typically respond to user input 3. The description of each 3D image, typically composed of triangles with parameters for application of image, or texture, data is generated by the CPU and this object data is sent to the rendering subsystem 4. This would use texture data stored in memory 5 to produce image data which would be constructed in a framebuffer in memory. The finished images would then be sent to the display system 6. In some systems, memory units 2 and 5 might actually be the same physical memory.
The known 3D rendering system 4 is now described in more detail with reference to FIG. 1b. The rendering system 4 consists of a unit 7 receiving polygon data. These polygon data are sent either individually or in batches to the rasterization unit 8 which determines which pixels in the final image are affected by which polygons and what colours to assign to the pixels. As part of this process, texture data must be accessed 9. This involves converting numerous requested texture identifiers and pixel coordinate positions into colour values and may require accesses to the 3D rendering system's memory via a memory control system 10. This memory control system would also handle framebuffer read and write requests from the rasterization unit 8. Finally, the display control system 11 would transfer finished images from the memory to the display device.
The aim of the invention is to ameliorate the problems associated with the known distribution techniques. In accordance with the present invention in a first aspect there is provided a texturing system according to claim 1. Preferred features of the texturing system are defined in dependent claims 2 and 3. Requiring the encrypted static texture data to be decrypted before it can be applied to the object data provides a means of protecting an application by making it difficult to copy the texture data in a way in which it could be used by another device to run the same application.
In accordance with a second aspect of the invention, there is provided a method of applying texturing to three-dimensional graphics data according to claim 4. Preferred steps in the method are defined in dependent claim 5.
In accordance with the present invention in a third aspect, there is provided a method of producing a software application according to claim 6. The software application is protected by the encryption of the static texture data so that only authorised devices can decrypt the static texture data and run the software application. Preferred features are defined in dependent claims 7 and 8.
In accordance with a fourth aspect of the invention, there is provided a method of distributing a protected software application from a distribution device to a target device in accordance with claim 9.
In accordance with a fifth aspect of the invention, there is provided a 3-d graphics device according to claim 10.
We have appreciated that many of the textures used by an application, especially games applications, will be created at the time the application is written. For the purposes of this patent, these will be referred to as static textures. Other textures may be produced while the application is running and these will be referred to as dynamic textures.
The aim of the invention is to make the widespread duplication of graphics software, in particular games software, difficult. It does this through a combination of protection circuitry within the rendering hardware and protection of the static texture data, rather than rely on obfuscation of the software, use of a protected CPU, and/or use of a proprietary storage medium. The invention resides in the realisation that by encrypting static texture data and controlling decryption of the texture data associated with a software application, the software may be protected from unauthorised use. The invention concerns a method of adapting computer graphics hardware with additional software production steps to inhibit widespread copying of such applications.
The system presented relies on the fact that a reasonable proportion of the computer graphics application, in particular a computer game, is static texture data which is prepared during the applications development. To protect the application, the standard 3D rendering hardware system is modified in five main ways. Firstly, each rendering chip has a unique, or at least very infrequently repeating, identification code embedded in it. Secondly, a set of secret keys is built into the silicon of the rendering chip and made virtually impossible to access. Knowledge of certain secret keys are then released only to trusted parties. Thirdly, some number of each application's externally stored textures are encrypted during development and are only decrypted within the 3D rendering chip by the texturing system during the rendering processes. Fourthly, the encrypted static textures are marked with a secure checksum so that rendering can be made to terminate if invalid texture data is supplied. Finally, the software delivery system is also modified so that it can modify or ‘tailor’ the software for a specific target device on which the application is to run.
It should be noted that dynamic textures, i.e., those generated by software whilst the application is running, are not encrypted/protected. If a symmetric (i.e. private key only) cipher were used, this would require storing the key in the application thus exposing it to a determined software pirate. An alternative would be to use a public/private key system, however, at present these are much slower, and so the time to encrypt the texture would make the technique undesirable in a real time system.